1. Technical Field
The invention relates to the field of data processing, and more particularly, to formatting data into markup language representations of data objects.
2. Description of the Related Art
Many issues can arise when integrating data between two or more applications. This is especially true when integrating data from different enterprise resource planning (ERP) systems and/or applications. For example, one application may utilize data objects for interacting with other applications while another application may store data in flat file form. If data is to be shared among the two applications, the data within the flat file must be converted or translated into a data object. Flat files, however, can be difficult to process due to the many possible data formats and file encodings.
One type of flat file, a comma separated value (CSV) file, consists of data organized in rows and columns with each element being separated by a comma. In a standard CSV file, all required data for an instance of an ERP data object is located in a row of a single CSV file. The column headers in the CSV file correspond to the field names in the ERP data object. For example, the structure of a CSV file typically is as follows: the first line contains the encoding of the file, the second line contains the column headers, and the third line contains the data associated with an individual occurrence of an ERP data object.
CSV files, however, do not always exist in standard format. Rather, numerous file format alternatives exist. For example, the data associated with a particular ERP data object may be contained in more than one CSV file. Other variations from the standard file format include cases in which CSV column names do not match the field names of the ERP object. Still, in other cases, CSV column data may map to multiple fields in the ERP object.
Integration service teams have developed several different techniques for dealing with the many different CSV file format variations. One technique has been to develop custom code to capture data from both standard and non-standard CSV file formats to subsequently populate ERP data objects. This technique provides streamline code which performs only those functions which are necessary to populate the ERP data objects. As a result, custom coded solutions often provide improved runtime performance. Still, limitations do exist. Specifically, developing custom code for each interface or engagement of different applications can be both time consuming and error prone. Additionally, the implementation and maintenance of custom code may require the customer to employ information technology (IT) support personnel. Finally, custom code may prove difficult to modify in the event that the ERP system is enhanced or expanded at some point in the future.
Another technique has been to capture ERP meta data within a database repository. Under this technique, rather than using custom code to generate data mappings, a graphical user interface (GUI) tool is provided for mapping the CSV file data to the appropriate fields of the ERP data object. As is known to those skilled in the art, meta data can provide a description of an interface to an application, in this case an ERP system data object. One benefit of the database technique is that all of the ERP system meta data is contained within a central repository.
The database technique does have disadvantages. In particular, to first load CSV data into a database, a mapping of each ERP system object first must be created. Additionally, the use of a database introduces another potential point of failure into a system. Another disadvantage of the database technique is that the overall runtime performance of a system decreases because of the frequent calls to the database to access the ERP system meta data.